Note verify

ABSTRACT

A validator having multiple modes of operation is contemplated. The validator may be operable in a standard mode where notes are escrowed and subsequently directed to a secure storage area depending on validity and a note-verify mode where notes are escrowed and subsequently returned to a user regardless of validity.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.14/532,145 filed Nov. 4, 2014, the benefit and the disclosure of whichis hereby incorporated in its entirety by reference herein.

TECHNICAL FIELD

The present invention relates to verifying notes, such as but notnecessarily limited to circumventing standard mode operations to permita note-verify mode where verification is performed prior to return ofthe note.

BACKGROUND

Safes, automated teller machines (ATMs), vending machines, video gamingunits and other devices may receive bank notes, coins, paper money orother valuables for safekeeping. More and more of these secure storageapparatuses are being manufactured with various electronicallycontrollable operations, including capabilities to verify notes prior tostorage. U.S. Pat. Nos. 5,918,720, 7,063,252 and 8,794,420 and U.S.patent application Ser. Nos. 13/248,000, 13/648,503 and 14/046,764, thedisclosures of which are hereby incorporated by reference in theirentireties, describe safes having such electronically controllableoperations, amongst others.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a secure storage apparatus in accordance withnon-limiting aspect of the present invention.

FIG. 2 illustrates an interior storage location of the secure storageapparatus as contemplated by one non-limiting aspect of the presentinvention.

FIG. 3 illustrates a flowchart of a verification process in accordancewith one non-limiting aspect of the present invention.

FIG. 4 illustrates an idle screen in accordance with one non-limitingaspect of the present invention.

FIG. 5 illustrates a valid screen in accordance with one non-limitingaspect of the present invention.

FIG. 6 illustrates an invalid screen in accordance with one non-limitingaspect of the present invention.

FIG. 7 illustrates a flowchart of a note verify process in accordancewith one non-limiting aspect of the present invention.

DETAILED DESCRIPTION

As required, detailed embodiments of the present invention are disclosedherein; however, it is to be understood that the disclosed embodimentsare merely exemplary of the invention that may be embodied in variousand alternative forms. The figures are not necessarily to scale; somefeatures may be exaggerated or minimized to show details of particularcomponents. Therefore, specific structural and functional detailsdisclosed herein are not to be interpreted as limiting, but merely as arepresentative basis for teaching one skilled in the art to variouslyemploy the present invention.

FIG. 1 illustrates a secure storage apparatus 10 in accordance withnon-limiting aspect of the present invention. The secure storageapparatus 10 corresponds with that described in U.S. patent applicationSer. No. 13/752,686 and may be configured to facilitate safekeeping ofdeposits, such as but not necessarily limited to deposits in the form ofcoins, paper currency, bills, documents, letters, boxes or other itemsthat may be electro-mechanically delivered through an exterior input forsafekeeping within an interior storage location. The secure storageapparatus 10 is predominately described with respect to being configuredas a safe having a sorter 12 configured as a bill validator operable toreceive and process paper currency for safekeeping, however othersimilar configurations may be used without deviating from the scope andcontemplation of the present invention (e.g., vending machines,automated teller machines (ATMs), video game machines, etc.). FIG. 2illustrates an interior storage location 14 of the secure storageapparatus 10 as contemplated by one non-limiting aspect of the presentinvention. The interior storage location 14 is shown to include a firstcassette 16 and a second cassette 18 operable with a first head 20 and asecond head 22 of the bill validator 12 to facilitate processing andsafe storage of paper currency. The secure storage apparatus 10 may beconfigured to facilitate servicing of the bill validator 12 whilemaintaining security of the currency kept within the first and secondstorage cassettes 16, 18.

The apparatus 10 may include a shutter 24 mounted or otherwise affixedto a door 25 to permit servicing of the bill validator 12 whilemaintaining security of the stored items. The shutter 24 may be movablepositionable relative to a first opening 26 in a substantially enclosedhousing 28 forming a body of the apparatus 10. The first opening 26 maybe sufficiently shaped within a side of the housing 28 to permit removalof the bill validator 12, one or more of the bill validator heads 20, 22or other component of the validator 12, therethrough. The door 25 may bemovable positioned relative to a second opening 30 in the side of thehousing 28. The second opening 30 may be shaped to permit removal of thecassettes 16, 18 or other storage container configured to receive thedeposit therethrough. The shutter 24 may be movable positioned between aclosed position and an opened position to respectively prevent andpermit removal of the bill validator. The door may be movable between aclosed position (see FIG. 1) and an opened position (see FIG. 2) torespectively prevent and permit removal of the storage cassette 16, 18.The shutter 24 may be configured in accordance with the presentinvention to permit removal of the bill validator 12 while the door 25is in the closed position, thereby enabling servicing of the billvalidator 12 without compromising security of the deposited items.

A door lock 34 may be included to lock the door 25 to the housingindependently of a shutter lock 36. (While shown on the door, the doorlock need not be included on the door may and may be positionedelsewhere to secure the door when in the closed position.) Like theshutter lock 36, the door lock 34 may be an electronically operable lockoperable between a locked state and an unlocked state in response tomessages and/or electronic signal. The door lock 34 is shown to includetwo bars that extend into a wall of the housing 28 when in the lockedstate to lock the door 25 in the closed position and that retract whenin the unlocked state to permit opening of the door 25. The door lock 34may be separately controllable from the shutter lock 44 such thatindividuals having capabilities may to open the shutter 24 may notnecessarily have capabilities to open the door 25. A human-machineinterface (HMI), touch-screen, display or other interface 40 (seeFIG. 1) may be included to facilitate electronically controlling variousoperations of the safe, including but not limited to the shutter lock 36and/or the door lock 34, such as through user inputs thereto. A cardreader 42 may also be included to read a secure card or magnetic stripconfigured to facilitate input of a code or other identifier needed tocontrol one or both of the locks. The HMI 40 and/or card reader 42 maybe housed below a top side of the housing 28 within a cavity 44. Apull-out tray 46 may be extended to position the HMI 40 and/or cardreader 42 outboard of the housing 28.

The HMI 40 may include a network interface (not shown) sufficient tofacilitate remote control and networking of the apparatus 10 and thehousing 28 may be enclosed in a sleeve (not shown), such as in themanner described in U.S. patent application Ser. No. 13/648,503, thedisclosure of which is hereby incorporated by reference in its entirety,and the applications and patents noted above. A switch 48 may beincluded to facilitate electronically controlling the shutter lock 44.The switch 48 may be a magnetic switch operable to indicate whether theshutter 24 is in one of the closed position and the opened positiondepending on whether a first magnet mounted to the shutter 24 is alignedwith a second magnet mounted to the door 25. The magnetic switch 48 maybe configured to facilitate closing a circuit to indicate the shutter 24being in the opened position when the first magnet aligns with thesecond magnet and to facilitate breaking the circuit to indicate theshutter 24 being in the closed position when the first magnet ismisaligned with the second magnet. While not shown, wires may extendfrom the shutter lock 36, the door lock 34 and/or the switch 48 tofacilitate electronic communications therewith and/or these componentsmay include wireless communication capabilities. A printer 50, such asbut not necessarily limited to a thermal printer, may be configured,such as with a printing element and a paper feed system, to facilitateprinting receipts 52. The printer 50 is shown to be on the face thepullout tray but may be positioned elsewhere, such as on a top of thetray next to the HMI 40 in order to provide a closer proximately andease of use when interacting therewith.

FIG. 3 illustrates a flowchart 60 of a verification method in accordancewith one non-limiting aspect of the present invention. The method may beembodied in a computer-readable medium having non-transitoryinstructions operable with a processor to facilitate verifying notes,such as but not necessary limited to verifying currency, bills, checks,or other material capable of being fed through the validator 12. Thesafe 10, validator 12 or a centralized network controller, such as theone described in U.S. Pat. No. 7,063,252, the disclosure of which ishereby incorporated by reference in its entirety herein, may be operablein accordance with the flowchart to facilitate some or all of theoperations and/or processes associated with the contemplatedverification method. The verification method is predominately describedfor non-limiting purposes with respect to the validator 12 beingconfigured to escrow currency notes for verification, such as todetermine whether the notes are valid or invalid or to generate otherinformation as a function thereof, e.g., to generate audit reports,values, etc. The validator 12 may be removable validator, such as theone described in U.S. Pat. No. 8,348,043, the disclosure of which isincorporated by reference in its entirety herein, or any other type ofvalidator having capabilities sufficient to facilitate the verificationprocess contemplated herein.

Block 62 relates to verification process beginning with one or morenotes being fed into the validator 12. While the validator 12 shown inFIG. 2 includes first and second mechanisms 20, 22 operable tofacilitate simultaneously verifying notes fed thereto, the presentinvention fully contemplates the safe 12 or other device having thevalidator 12 being configured with a single validator mechanism and/oradditional validator mechanisms. The present invention may also beoperable in a networked environment having multiple validators connectedto a centralized network controller operable to monitor, control andotherwise manipulate or control operations of multiple validators 12and/or safes 10. The verification method may be particularly beneficialwhen a need arises to verify a note prior to accepting it as payment ina point-of-sale (POS) system where a cashier (user) keeps money in atill for the purposes of recording sales and making change withcustomer, e.g., to verify authenticity of a $100 bill prior to acceptingit as tender for a transaction. In this exemplary use case, the cashiermay feed the $100 bill to the validator 12 in manual operation but thepresent invention would be equally useful in an automated process.

Block 64 relates to determining whether the validator 12 has beenprogrammed to operate in a standard mode or a note-verify mode. Thestandard mode may correspond with typical or normal operation where thevalidator 12 is being used to verify and process submitted notes forstorage within the secure storage area 14. The note-verify mode maycorrespond with a non-typical or temporary mode of operation where thevalidator 12 is being used to verify and process submitted notes for thepurposes of returning it to the cashier rather than storing it in thesecure storage area 14. While only the standard and note-verify modesare described, the present invention fully contemplates the safe 10 orother device having the validator 12 being operable in any number ofadditional operational modes. The determination of whether the validator12 is operating in the standard mode or the note-verify mode may bebased on control signals or user inputs thereto. The HMI 40 may beoperable to display a button sufficient for switching between thestandard and note-verify modes. One non-limiting aspect of the presentinvention contemplates a scenario where the cashier instigates a singlemanipulation of a mode-switch button included on the HMI 40 to switchfrom the standard mode to the note-verify mode and/or from thenote-verify mode back to the standard mode. Optionally, a timer or otherdefault control may be implemented to automatically revert from thenote-verify mode back to the standard mode.

Block 66 relates to the standard mode being currently active uponreceipt of the note. The validator 12 may include a sensor or otherfeature capable of sensing presence of the bill prior to beginning afeed-in/escrow process so as to facilitate determining presence of thenote prior to the note being mechanics driven into the validator 12.Block 68 relates to the validator 12 performing a verification processwhere the note is determined to be valid or invalid. A validdetermination may occur when the node is determined to be genuine and aninvalid determination may occur when the note is determined to be fakeor incapable of being scanned/process for the purposes of assessingvalidity, e.g., in the event the note distorted, ripped or otherwisedefective. The valid and invalid determinations are described forexemplary non-limiting purposes as illustrative of various operationscapable of being performed with the bill validator 12 to adjudicate orotherwise assess the received note. Additional operations and/orprocesses may be performed in the standard mode and/or the note-verifymode without deviating from the scope and contemplation of the presentinvention. The verification process may include the note being escrowedentirely within the validator 12 such that it is out-of-sight of theuser or otherwise entirely lodged within the validator 12, such as toenable a scanner or other device to assess authenticity.

Block 72 relates to the validator 12 facilitating delivery of a notedetermined to be valid for safekeeping. Block 74 relates to thevalidator 12 returning a note determined to be invalid. The validator 12may include a first interface through which a user feeds the note and asecond, different interface through which the note may be delivered forstorage such that returned notes may be delivered back through the firstinterface and accepted notes may be delivered through the secondinterface. At the conclusion of the verification process, an auditreport or other information may be generated by the validator 12 and/orinformation may be provided from the validator 12 to a controller foruse in monitoring the corresponding transaction. The exemplarydescription of the standard mode may include any number of otheroperations and processes to be performed by the validator 12 or otherdevice associated with the safe 10. The standard mode may be generallycharacterized by an intention to keep or otherwise prevent return of thesubmitted note to the user if found to be valid, authenticated orotherwise suitable for safekeeping. While described with respect tokeeping valid notes, the notes may also be retained or kept even iffound to be invalid, such as to prevent its continued circulation.

Block 76 relates to determining to the note-verify mode being currentlyactive upon receipt of the note. FIG. 4 illustrates an idle screen 78appearing within the HMI 40 of other display associated with the safe10, such as display included on the cash register or in a locationcommon to multiple cashiers, according to the note-verify mode inaccordance with one non-limiting aspect of the present invention. Theidle screen 78 is shown to include a button 80 for returning to a homepage (not shown) or to switch back to the standard mode, a help button82 for viewing/printing instructions, such as in the manner described inSer. No. 14/046,764, the disclosure of which is hereby incorporated byreference in its entirety herein, and an instructive illustration 84directing the user to insert the note to the validator 12. In the eventa display is viewable to multiple cashiers or users, the idle screen 78may act as an alert to the other user that another user is attempting toimplement the note-verify mode. While not illustrated, the idle screen78 may include other user-selectable features, such a type feature wherethe user identifies the type of note desired for use with thenote-verify mode, e.g., paper currency, check, money order, etc.

Block 88 relates to transmitting shutdown message upon detectingpresence of the note to prevent other validators 12 or validatormechanisms 20, 22 from simultaneously operating according to thenote-verify mode. The ability to prevent other validators or validatormechanism, particularly those in proximity to the first one being fedthe note or those connected to a common networked infrastructure, may bebeneficial in preventing user confusion when multiple userscontemporaneously attempt to implement the note-verify mode. Theshutdown message may be sufficient to prevent any subsequent validatorsfrom feeding or accepting notes, and thereby act as notification to thecorresponding user that the note-verify mode has not been implement atthe corresponding validator. Optionally, the shutdown message mayprevent the other validators from processing any notes or to enableother validators to operate according to other modes besides thenote-verify mode. The shutdown message may be transmitted locally withinthe safe 10 to prevent one of the other one of the mechanisms 20, 22from operating and/or through a network interface to prevent othernetwork-connected validators from operating.

Block 90 relates to the validator 12 escrowing the received note andassessing it to be one of valid and invalid in the manner describedabove with respect to the standard mode. Optionally, the verify-mode maydeem notes to be valid or invalid according to other metrics than thoseutilized in the standard mode, e.g., the standard mode may be limited toprocessing only certain type of notes suitable for storage, such aspaper currency and not checks, while the note-verify mode may performother valid and invalid assessments for notes incapable of being storedin the safe 10 due to the notes being subsequently returned to the userregardless of validity. The note-verify mode may be operable with anytype of note capable of being processed through the validator even ifthe safe is unable to store it. Blocks 92, 94 relate to the return ofvalid and invalid notes to the user, such as with delivery of the notefollowing escrow back through the first interface. Block 96 relates to averification message being generated to indicate whether the note wasdetermined to be valid or invalid. The verification message be displayedvia the HMI 40 or other display in communication with the safe and/orthe verification message may be transmitted to a centralized networkcontroller for the purposes of generating an audit for the note.Optionally, the verification message may be used to control to open acashier till if valid and to prevent the cashier till from opening ifinvalid, which may be useful in providing cashiers with a secondarynotification of validity.

FIG. 5 illustrates the verification message facilitating display of avalid screen 100 following a successful validation according to thenote-verify mode in accordance with one non-limiting aspect of thepresent invention. The valid screen 100 may include the featuresdescribed above with respect to FIG. 4 as well as a valid indicator 102sufficient to alert the user of the valid determination, and optionally,a value for the note, e.g., $100 note. The valid screen 100 mayoptionally include a re-verify button 104 sufficient to automaticallyengage the note-verify mode for a subsequently submitted note, which maybe beneficial in the even the validator 12 automatically defaults to thestandard mode once the note-verify mode completes. FIG. 6 illustratesthe verification message facilitating display of an invalid screen 106following a successful validation according to the note-verify mode inaccordance with one non-limiting aspect of the present invention. Theinvalid screen 106 may include the features described above with respectto FIGS. 4 and 5 as well as an invalid indicator 108 sufficient to alertthe user of the invalid determination, which may optional identify thenote as being non-genuine or incapable of being scanned. A cashier mayreview the valid/invalid screens prior to accepting the note as tenderfor a transaction, thereby providing an authenticity feedback prior toplacing the note in the till or otherwise closing the transaction.

The foregoing standard and note-verify modes are predominately describedwith respect to processing a single note for verification purposes. Thisis done without necessarily intending to limit the scope andcontemplation of the present invention as multiple notes may beprocessed prior to determining validity and/or validity may bedetermined individually for multiple notes passing through the validator12 in succession, i.e., the valid and invalid screens may display serialnumbers or other identifiers sufficient for individually identifyingeach note as being valid and/or invalid. The note-verify mode may verifya currency note as a valid note by extending the functionality of a billvalidator for purposes of recognition and identification of the papernote currency inserted with the bill validator. A function may place thebill validator in a state known as escrow where the paper currency notecan be read but not acted upon by the system. The function may thenreturn the note without accepting the note to the presenting user andthe function may read the state of the note and any potential value ofsaid note. The function may then provide one of two responses to theuser. An example of the first response is to inform the user via a userinterface that the note could not be validated by the bill acceptor. Anexample of the second possible response would inform the user via a userinterface that the note was validated and display the value of the note.

FIG. 7 illustrates a flowchart 110 of a note verify process inaccordance with one non-limiting aspect of the present invention. Onenon-limiting aspect of the present invention contemplates thenote-verify feature providing a way for users of the system to use anynote acceptor peripherals to validate a received note. Either the noteis validated and the scanned value of the note is presented to the user,or the note cannot be identified and a warning message is presented tothe user. This does not necessarily mean that the note is a counterfeitor otherwise a bad Note. Occasionally there is some kind of damage tothe note either in parts missing, tearing, or markings on the note thatcan render it unreadable by a note acceptor. The process flow in FIG. 7shows a number of steps in a builder (steps [A]-[L]). The sections belowwill define each of these steps.

Builder Step [A]—Idle Screen

The call to start the process will come from the idle screen. This isthe logged out idle screen that the system is normally at when no usersare logged in.

Builder Step [B]—Process Initiated

Once the process is initiated from the idle screen, the builder starts.It is not the responsibility of this builder to check to see if thereare validators in the Local Node that the MCU is a part of. That logicis to be performed by the calling builder.

At this point in the process, any validators in the Local Node that arenot part of a User Lock process should be enabled. As the Verify Noteprocess does not accept any Money into the system or modify any Fundtotals, any Note Acceptor in the Local Node system can be used no matterwhat Fund it is associated with.

Builder Step [C]—Verify Note Screen

There may be only one screen for the Verify Note process that is usedthroughout. This screen at this stage in the process flow only has twoactions available for the user.

-   -   The first action is a ‘Back’ button that exits the process and        takes the user back to the idle screen. There are no permissions        or logic associated with the ‘Back’ button.    -   The second action available to the user is to insert a Note into        one of the Note Acceptors that are active as part of the Verify        Note process.

It is assumed that any Note Acceptors in any other state are known tothe user and will continue to function in that other state while thisprocess is going on.

Builder Step [D]—User Inserts a Note

As soon as a Note Acceptors recognizes that a Note has been inserted,all Note Acceptors associated with the Verify Note process should ceaseacceptance of Notes. Only the first Note put into a Note Acceptor shouldattempt to be validated.

Builder Step [E]—Validating the Note

After all other Note Acceptors have been disabled from accepting newNotes; the Note that was entered should now be in an escrow state in theNote Acceptor that it was inserted into. The state of the Note should beread from the Note Acceptor.

Builder Step [F]—Return Note to User

At this point the note should be rejected no matter the outcome of thevalidation process. The Verify Note process should never stack or accepta Note past the point of escrow.

Builder Step [G]—User Inserts a Note

Here the state of the Note that was read should be examined. A decisionpoint exists here that is based on whether the Note was read as valid ornot. This decision point affects the next two steps.

Builder Step [H]—Verify Note Screen with Warning

At this point in the process a Note has been read and it was unable tobe validated by the Note Acceptor. The user has two options at thispoint:

-   -   Press the ‘Back’ button which will exit this process and take        the user back to the idle screen. Again, there are no        permissions or logic associated with the ‘Back’ button.    -   Press the ‘Re-Verify Note’ button. When pressed, the process        flow will revert back to step [B] and continue from there.

Builder Step [I]—Verify Note Screen with Valid Note message and Notevalue been read and it was read and validated by the Note Acceptor. Theuser has two options at this point in the process:

-   -   Press the ‘Back’ button which will exit this process and take        the user back to the idle screen. Again, there are no        permissions or logic associated with the ‘Back’ button.    -   Press the ‘Re-Verify Note’ button. When pressed, the process        flow will revert back to step [B] and continue from there.

Builder Step [J]—User Input Needed

This step just indicates that the process is dependent on the usermaking a selection at this point. The process will not continue until aselection is made.

Builder Step [K]—‘Re-Verify’ Button press

Here the user has selected the ‘Re-Verify’ button. This event inanalogous to starting the process from the beginning and the processflow should start again at step [B].

Builder Step [L]—‘Back’ Button press

Here the user has selected the ‘Back’ button. This event exits thisprocess and takes the user back to the idle screen and completes theVerify Note process.

Additional Verify Note Module Considerations

The Verify Note process has a few additional considerations that need tobe taken into account during the development of the module. Theseconsiderations are defined in the sections below.

Verify Note Process Error Handling

No specific error handling logic is needed for this process. The firstNote Acceptor that registers that a Note has been submitted forvalidation is the one that will be used for the validation process. Thiswill eliminate conditions where simultaneous notes are put intodifferent Note Acceptors to try and game the system.

Verify Note Process Accounting

The Verify Note process is not associated with any Funds or Fund Totals.At no point in the Verify Note process should any Note ever be stackedin a Note Acceptor. At no point in the Verify Note process should anytotals be queried or modified.

Verify Note Process Auditing

Every time a Note is read for validation in the Verify Note process anaudit is created in the System Audit. This audit record will contain thedefault audit timestamp. Because no user login precedes running theVerify Note process the system has no way of knowing what user isperforming the process, therefore the user for the audit is the‘System’. The audit record will contain the results of the validationand, if valid, the value of the validated Note. The specific audit datacan be found in Appendix E—Ascent Platform Audit Detail.

Verify Note Process Screen Timeouts

The screens used in the Verify Notes process will have associated screentimeouts. These screen timeouts will be settings based, and reflect theglobal settings ‘screen_timeout_active’ and ‘screen_timeout_time’. Ifthe setting ‘screen_timeout_active’ is set to ‘Y’ then all screens inthis process need to timeout after x seconds, with x being an integervalue represented in the setting ‘screen_timeout_time’. If‘screen_timeout_active’ is set to ‘N’ then no screen timeouts will occurin this process.

The screen timeout is a timer that resets on any user interaction withthe system. This could be in the form of touch on a touchscreen, orinserting a Note into an activated Note Acceptor, or causing a sensor totrigger. The latter could be something like closing a Vault door. Uponreset, the timer will start counting seconds again. If the timer reachesthe ‘screen_timeout_time’ then the screen timeout action occurs. Thescreen timeout action for the Verify Note process is to close theprocess and pass navigation back to the idle screen.

Note that if a screen timeout occurs during the part of the processwhere any Note Acceptors are in use, any Note Acceptors associated withthis Verify Note process should be disabled and placed back into an idlestate.

Verify Note Process Help Button

In the top navigation bar on the screen used for the Verify Noteprocess, there is a circular button with a ‘?’ inside it. That buttonwill bring up the Help overlay for this module. No matter when thebutton is pressed during this process, the help overlay will display thesame instructions for the process and will not change depending on whatpart of the process the user is in. The Help overlay will contain 2buttons, a ‘Close’ button and a ‘Print’ button. The ‘Print’ button canbe used to print a copy of the help navigation. The ‘Close’ button canbe used to close the Help overlay and continue on in the Verify Noteprocess.

Note that the Help section is referred to as an overlay meaning that itwill ride on top of the existing screen with the underlying processstill ongoing. Therefore screen timeouts will also apply to the Helpoverlay as well as the underlying screen.

Verify Note Process Navigation Cost

The navigation cost for an expected run through the Verify Note Processalone is 1+t¹+1+t²+1. The first 1 indicates the button press to startthe process. The value of t¹ is the amount of time for a user to inserta Note into a Note Acceptor. The second 1 indicates an estimated lengthof time for the Note Acceptor to read the Note and then pass the Noteback out of the Note Acceptor. The value of t² is the amount of time fora user to take the note and read the results of the verification processonscreen. The final 1 denotes the single button press to complete theprocess.

Consolidating the navigation cost down to 3+t1+t2 gives a condensedcost. Assuming a trained user of the system taking anywhere from 1-10seconds for both t1 and t2, we get a theoretical best-worst casenavigation cost for a trained user of 5-23 seconds to complete theVerify Note process.

There is master audit data stored for every audit in the system. Thismaster data comprises the user information for each audit, a timestamp,an audit type, and a master data field that stores the xml for themaster audit. The master audit data also stores a master id which is anauto-incrementing field that stores a consecutive counting number thatindicates the position of the audit against all others in the system.This piece of data is even more important than the timestamp in that itrepresents an ordering of the data sequentially and will exist even ifthe realtime clock in the system is not operating correctly or istampered with.

Master Audit XML Format

The master audit XML format is as follows:

<audit_master>    <audit_master_id>1</audit_master_id>   <user_id>1</user_id>    <user_name>Bob</user_name>   <audit_timestamp>2014-09-02 16:22:12</audit_timestamp>   <audit_type_id>1></audit_type_id> </audit_master>

System Audit Data:

Audit: Verify Note Completed Audit Number: XX Parameters:   • ValidNote, <valid_note>      ∘ Indicates whether the note read was valid ornot      ∘ Values can be Y or N   • Note Value, <note_value>      ∘ If<valid_note> is Y then this records the value of the        read noteSample XML: <system_audit>    <valid_note>Y</valid_note>   <note_value>$100</note_value> </system_audit>

While exemplary embodiments are described above, it is not intended thatthese embodiments describe all possible forms of the invention. Rather,the words used in the specification are words of description rather thanlimitation, and it is understood that various changes may be madewithout departing from the spirit and scope of the invention.Additionally, the features of various implementing embodiments may becombined to form further embodiments of the invention.

What is claimed is:
 1. A safe comprising: a secure storage area for storing notes; and a validator having a first interface for exchanging notes with a user and a second interface for directing notes to the secure storage area, the validator being operable in a standard mode where valid notes are directed through the second interface for safekeeping in the secure storage area and in a note-verify mode where valid notes are directed back through the first interface to the user.
 2. The safe of claim 1 wherein the note-verify mode includes the validator generating a verification message indicating whether a note is at least one of valid and invalid.
 3. The safe of claim 2 wherein the note-verify mode includes the validator indicating a value of the note within the verification message.
 4. The safe of claim 2 further comprising a display operable with the validator to facilitate display of the verification message to the user.
 5. The safe of claim 2 further comprising a network interface operable with the validator to facilitate transmission of the verification message over a network to a control device.
 6. The safe of claim 1 wherein the validator escrows a note in both of the standard mode and the note-verify mode such that an entirety of the note is at least temporarily out-of-sight within the validator prior to being subsequently directed to one of the first and second interfaces.
 7. The safe of claim 1 further comprising a touch-screen display operable to interface a note-verify button with the user, the note-verify button operable for controlling the validator between the standard mode and the note-verify mode.
 8. The safe of claim 1 wherein the validator performs a verification process when operating according to either one of the standard and note-verify modes to determine whether a note is at least one of valid and invalid, the verification process requiring the note to be at least temporarily escrowed within the validator and thereafter directed towards one of the first and second interfaces depending on whether the validator is operating in the standard or the note-verify mode and whether the note is valid or invalid.
 9. The safe of claim 8 wherein the validator: escrows and then directs the note to the second interface if valid when operating according to the standard mode; escrows and then directs the note to the first interface if invalid when operating according to the standard mode; and escrows and then directs the note to the first interface if valid when operating according to the note-verify mode; and escrows and then directs the note to the first interface if invalid when operating according to the note-verify mode.
 10. The safe of claim 8 wherein the validator includes a first mechanism and a second mechanism configured to independently and simultaneously perform the verification process on notes interfaced therewith at least when the validator is operating according to the standard mode, including escrowing and then directing the notes to one of the first and second interfaces depending on whether the notes are valid or invalid.
 11. The safe of claim 10 wherein the validator shuts down one of the first and second mechanisms when operating according to the note-verify mode such that only one of the first and second mechanisms is operable to perform the verification process.
 12. The safe of claim 11 wherein the validator shuts down the first mechanism when operating according to the note-verify mode if the second mechanism is fed a note before the first mechanism is fed a note and wherein the validator shuts down the second mechanism when operating according to the note-verify mode if the first mechanism is fed a note before the second mechanism is fed a note.
 13. A non-transitory computer-readable medium having a non-transitory instructions operable with one or more validators to facilitate electronically validating notes fed from a user, the non-transitory instructions being sufficient for: performing a standard verification where the validator escrows and assesses notes to be at least one of valid and invalid and thereafter directs valid notes for storage and returns invalid notes to the user; and performing a note-verify verification where the validator escrows and assesses notes to be at least one of valid and invalid and thereafter returns both valid and invalid notes to the user.
 14. The non-transitory computer-readable medium of claim 13 wherein the non-transitory instructions are sufficient for facilitating display of a verification message when operating according to the note-verify mode, the verification message indicating whether a note is valid or invalid.
 15. The non-transitory computer-readable medium of claim 14 wherein the non-transitory instructions are sufficient for displaying value of the note as part of the verification message if the note is valid.
 16. The non-transitory computer-readable medium of claim 13 wherein the non-transitory instructions are sufficient for transmitting a shutdown message to a first validator of the one or more validators to prevent the first validator from operating according to the note-verify mode when a second validator of the one or more validators switches from the standard mode to the note-verify mode.
 17. A safe comprising: a secure storage area for storing paper bills; and a bill validator configured to mechanically feed the paper bills from a user to the secure storage area, the bill validator being operable in a note-verify mode where the bill validator: i) escrows a first one or more of the paper bills; ii) determines each of the first paper bills to be at least on of valid and invalid; and iii) returns the each of first paper bills to the user.
 18. The safe of claim 17 wherein the bill validator is further operable in a standard mode where the bill validator: escrows a second one or more of the paper bills; determines each of the second paper bills to be at least on of valid and invalid; feeds each of the second paper bills determined to be valid to the secure storage area; and returns each of the second paper bills determined to be invalid to the user.
 19. The safe of claim 18 wherein the further comprising a display operable to display a verification message as a function of information received from the bill validator while operating according to the note-verify mode, the verification message individually indicating whether each of the first bills returned to the user is the at least one of valid and invalid and a value for each of the first bills determined to be valid.
 20. The safe of claim 19 wherein the display is a touchscreen and the bill validator is operable between the note-verify mode and the standard mode as a function of a single actuation of a note-verify button shown within the touchscreen, the bill validator being unable to simultaneously operate in both of the standard and note-verify modes. 